使用 CDN / WAF 时，正常访问链路通常为：
greenyang361
用户
│
▼
DNS
│
▼
CDN / WAF 节点
│
▼
源站服务器（Origin Server）
例如：
www.example.com
│
▼
CDN IP：203.0.113.10
│
▼
Origin IP：198.51.100.20
正常情况下，互联网用户只能看到 CDN/WAF 节点地址，而不应该直接知道源站公网 IP。
“获取源站 IP”和“利用 Web 漏洞”属于两个不同阶段的问题。
主要影响网络层和服务暴露面。
一旦源站公网 IP 暴露，攻击者可能绕开 CDN/WAF 的入口，直接访问源站。
可能产生的风险包括：
源站 IP 泄漏
│
├── 绕过 CDN
├── 绕过部分 WAF 防护
├── 直接扫描源站开放端口
├── 暴露 SSH / 数据库 / 管理接口等服务
├── 针对源站直接进行流量攻击
└── 直接测试 Web 应用漏洞
需要注意：
知道源站 IP ≠ 已经攻破服务器。
它只是使攻击面扩大，并可能让原本依赖 CDN/WAF 过滤的防御失效。
Webshell、远程代码执行等通常依赖：
文件上传漏洞
RCE
命令注入
反序列化漏洞
模板注入
Web 框架漏洞
错误配置
这些属于应用层安全问题。
因此：
发现源站 IP
↓
绕开 CDN / WAF
↓
直接访问 Origin
↓
扩大攻击面
↓
寻找源站自身存在的漏洞
而不是：
发现源站 IP
↓
自动获得服务器权限 ×
源站发现本质上可以分成两个阶段：
第一阶段：寻找 Candidate Origin IP
│
▼
第二阶段：验证 Candidate 是否真的是 Origin
常见信息来源：
Target Domain
│
┌──────────────┼──────────────┐
│ │ │
▼ ▼ ▼
DNS / 子域名 TLS / 证书 Web / API
│ │ │
├──────────────┼──────────────┤
│ │ │
▼ ▼ ▼
邮件系统 网络空间搜索 主动出站
│ │ │
└──────────────┼──────────────┘
▼
Candidate Origin IP
│
▼
特征验证
│
▼
Confirm Origin
这是最经典的源站泄漏来源之一。
很多网站并不是从上线第一天就使用 CDN。
例如：
2022：
example.com → 198.51.100.20
2025：
example.com → CDN
2026：
example.com → CDN
虽然现在 DNS 已经指向 CDN，但是以前的 DNS 解析结果可能已经被第三方平台长期保存。
这就是：
Historical DNS
常见历史信息包括：
A
AAAA
CNAME
MX
NS
TXT
因此分析时不能只关注 A 记录。
IPv4 地址：
example.com → 198.51.100.20
如果这个地址出现在 CDN 接入之前，就可能是历史源站。
这是实际排查中容易忽略的一点。
有些管理员只隐藏了 IPv4：
A → CDN
但是 IPv6 仍然直接指向服务器：
AAAA → Origin IPv6
因此：
检查 CDN 隐藏情况时，IPv4 和 IPv6 必须同时检查。
例如：
example.com
│
└── MX → mail.example.com
│
└── A → 198.51.100.20
如果 Web 和 Mail 部署在同一服务器或者同一公网出口上，就可能间接暴露源站网络信息。
但要注意：
MX IP 不一定等于 Web Origin IP。
它只能作为关联线索。
这是另一个非常常见的问题。
主站可能已经接入 CDN：
www.example.com → CDN
但是其他子域名可能直接解析源站：
api.example.com
admin.example.com
dev.example.com
test.example.com
stage.example.com
staging.example.com
mail.example.com
smtp.example.com
vpn.example.com
origin.example.com
backend.example.com
old.example.com
典型错误架构：
CDN
│
www.example.com ──┤
│
▼
198.51.100.20
▲
│
api.example.com ──┘
此时：
api.example.com → 198.51.100.20
可能直接暴露与主站相同的服务器。
除了当前子域名，还需要关注历史业务系统，例如：
old.example.com
legacy.example.com
beta.example.com
demo.example.com
test.example.com
dev.example.com
常见情况是：
旧系统
↓
没有下线
↓
仍然解析旧服务器
↓
旧服务器后来成为正式站源站
因此旧资产也是源站泄漏的重要来源。
同一服务器可能运行多个网站：
198.51.100.20
│
├── example.com
├── example.net
├── company-test.com
└── old-project.com
其中：
example.com → CDN
但：
old-project.com → 198.51.100.20
于是另一个没有 CDN 的网站可能间接暴露服务器地址。
这属于：
Virtual Host / 旁站关联
因此资产分析不能只关注一个域名，还需要考虑：
Domain
Subdomain
IP
ASN
Hosting Provider
Certificate
Virtual Host
之间的关联关系。
邮件是非常经典的源站网络信息泄漏来源。
例如网站具有：
注册验证邮件
密码重置邮件
订单邮件
系统告警邮件
邮件通常经历：
Web Server
│
▼
SMTP
│
▼
Mail Server
│
▼
用户邮箱
完整邮件 Header 中可能存在：
Received:
Message-ID:
X-Originating-IP:
等字段。
其中可能记录邮件经过的服务器。
但需要注意：
现代网站大量使用：
第三方邮件服务
云邮件网关
独立 SMTP Server
NAT Gateway
邮件代理
因此邮件中看到的公网 IP：
不一定是 Web Origin IP，只能作为候选信息进一步验证。
另一个重要思路是：
如果服务器主动访问外部资源，那么外部服务器可能看到它的出口 IP。
正常 CDN 流量：
Client
↓
CDN
↓
Origin
服务器主动出站：
Origin
↓
Internet
↓
External Server
第二条路径通常不会经过 CDN。
因此可能暴露：
Origin Public IP
或者：
NAT / Egress Gateway IP
注意二者不能直接画等号。
一些 Web 功能需要服务器主动访问用户提供的 URL，例如：
远程图片抓取
URL Preview
Webhook
URL Screenshot
远程文件导入
RSS
网页抓取
PDF 转换
第三方接口回调
例如：
用户提交 URL
│
▼
Web Application
│
▼
Backend Fetcher
│
▼
Remote Server
如果 Remote Server 属于测试人员控制，那么日志中可能看到请求来源。
但看到的地址可能是：
Web Origin
NAT Gateway
Proxy
Serverless Egress
Kubernetes Node
云厂商出口地址
因此仍然需要进一步验证。
这类功能经常被忽略。
例如：
HTML → PDF
URL → Screenshot
网页预览
OpenGraph Preview
富文本远程图片加载
后台可能运行：
Chromium
Playwright
Puppeteer
wkhtmltopdf
ImageMagick
其他渲染服务
如果渲染过程中加载远程资源：
Backend Renderer
│
▼
External Resource
外部服务器可能记录后台渲染服务的出口 IP。
例如：
Webhook URL
Callback URL
Notification URL
Payment Callback Test
服务器主动访问用户指定地址：
Application
│
▼
Webhook Worker
│
▼
External Server
同样可能产生网络出口信息泄漏。
HTTPS 普及以后，TLS 证书成为非常重要的服务器识别特征。
例如源站服务器直接配置：
example.com certificate
互联网扫描系统扫描：
IP:443
服务器可能返回：
Certificate:
CN = example.com
SAN = example.com
www.example.com
于是形成：
Certificate
│
▼
IP
的关联。
公开 CA 签发的很多证书都会进入：
Certificate Transparency Logs
CT Logs 可以帮助发现：
example.com
www.example.com
api.example.com
admin.example.com
dev.example.com
等证书中出现过的域名。
需要理解：
CT Logs 更擅长发现“域名/子域名”，并不意味着 CT 日志本身直接记录源站 IP。
常见分析链：
CT Logs
↓
发现 Subdomain
↓
DNS / Internet Scan
↓
发现 Candidate IP
除了域名，还可以利用证书本身的特征建立资产关系，例如：
Certificate SHA-256 Fingerprint
Issuer
Subject
SAN
Serial Number
Validity
如果：
CDN 后的网站
和某个公网 IP：
IP:443
出现高度相关的证书特征，该 IP 就可能成为候选源站。
不过：
共享证书、泛域名证书、反向代理和共享托管都会造成误报，因此证书匹配不能单独作为最终结论。
互联网资产搜索平台会持续扫描公网服务，例如：
HTTP
HTTPS
SSH
FTP
SMTP
RDP
数据库
各种 TCP 服务
并记录：
IP
Port
Banner
HTTP Header
TLS Certificate
HTML Title
HTML Hash
ASN
Organization
Technology Stack
因此可以利用：
Domain → Certificate
Certificate → IP
Domain → Historical IP
HTML Fingerprint → IP
建立资产关联。
Web 应用本身也可能暴露服务器网络信息。
常见来源：
Debug 页面
错误堆栈
配置文件
源码泄漏
备份文件
日志文件
测试接口
监控接口
phpinfo
.env
Git / SVN 遗留
API Debug Response
例如错误信息可能出现：
backend = 10.0.1.15
proxy_pass = 198.51.100.20
API_SERVER = ...
DATABASE_HOST = ...
需要区分：
10.x.x.x
172.16.x.x - 172.31.x.x
192.168.x.x
属于私有地址，本身无法直接从互联网访问。
但这些信息可以帮助理解后台网络拓扑。
现代 Web 应用大量使用 JavaScript。
前端代码中可能出现：
API_BASE_URL
WebSocket URL
Upload Server
Media Server
Legacy API
Internal Hostname
Debug Endpoint
例如：
api.example.com
ws.example.com
media.example.com
upload.example.com
这些地址可能指向与主站不同的基础设施。
因此：
HTML
↓
JavaScript
↓
API Endpoint
↓
DNS / TLS / Network Relationship
也是资产发现的重要链路。
有些网站：
HTTP → CDN
但是：
WebSocket → 独立服务器
例如：
wss://ws.example.com
如果 WebSocket 子域名没有经过 CDN/WAF，就可能暴露后台服务器或相关网络。
Web 页面可能经过 CDN：
www.example.com
但真正的数据服务可能使用：
RTMP
RTSP
HLS Origin
WebRTC
Media API
Streaming Gateway
例如：
Browser
│
├── HTTPS → CDN
│
└── Streaming → Media Server
如果媒体基础设施和 Web 源站位于相同服务器或网络环境，就可能产生关联线索。
CDN 通常主要代理特定协议和端口。
服务器可能同时运行：
80 HTTP
443 HTTPS
22 SSH
25 SMTP
3306 MySQL
5432 PostgreSQL
6379 Redis
其他业务服务
即使：
80/443 → CDN
其他服务仍可能直接暴露公网。
如果某个公网 IP 的：
SSH Banner
TLS Certificate
HTTP Title
服务版本
与目标基础设施高度相关，也可能成为候选源站。
防御重点不是“隐藏这些 Banner”，而是：
根本不要把不需要公网访问的管理端口和数据库端口暴露到互联网。
部分源站泄漏并不是复杂技术造成的，而只是配置错误。
例如：
example.com → CDN
origin.example.com → Origin
甚至：
direct.example.com
backend.example.com
origin.example.com
直接公开存在。
另外还可能出现：
IPv4 → CDN
IPv6 → Origin
或者：
www → CDN
apex/root domain → Origin
例如：
www.example.com → CDN
example.com → Origin
因此应同时检查：
Root Domain
www
IPv4
IPv6
所有业务子域
发现 IP 后不能马上认定它就是源站。
必须区分：
Candidate Origin
和：
Confirmed Origin
验证通常基于多个特征组合。
比较：
HTML
Title
Static Resource
Favicon
Redirect
Error Page
是否高度一致。
例如：
Server
Set-Cookie
Content-Type
Cache-Control
自定义 Header
需要注意：
CDN 本身可能：
添加 Header
删除 Header
修改 Header
压缩内容
缓存内容
因此不能要求所有 Header 完全一致。
例如应用可能返回：
SESSIONID
JSESSIONID
PHPSESSID
Laravel Session
自定义 Cookie
Cookie 名称和行为可以作为应用指纹的一部分。
页面中的：
favicon.ico
HTML
JS Bundle
CSS
可以计算 Hash 进行关联。
思路：
CDN Website
│
▼
Content Fingerprint
│
▼
Candidate IP
如果多个特征一致，可信度会提高。
进一步比较：
Certificate
SAN
Issuer
TLS Configuration
Protocol Support
但仍然要注意共享证书和共享服务器导致的误报。
现代 Web Server 经常运行多个网站：
Server IP
│
├── site-a.com
├── site-b.com
└── site-c.com
因此直接访问：
https://IP/
可能只能得到：
Default Site
403
404
并不能证明该 IP 与目标无关。
HTTP 虚拟主机通过：
Host
区分站点。
HTTPS 还涉及：
SNI
因此在授权测试中，候选源站验证必须理解：
IP
Host
SNI
Virtual Host
之间的关系。
错误。
邮件服务器可能完全独立。
错误。
同一网段可能运行成千上万个完全无关的服务器。
不一定。
可能存在：
Wildcard Certificate
Shared Hosting
Reverse Proxy
Load Balancer
不一定。
可能经过：
NAT Gateway
Proxy
Cloud Egress
Service Mesh
不一定。
源站自身可能还有：
Host Validation
mTLS
Origin Authentication
Security Group
Firewall
第二层 WAF
可以把整个过程理解成：
Target
│
▼
Domain Information
│
┌──────────────┼──────────────┐
▼ ▼ ▼
Historical DNS Subdomains CT Logs
│ │ │
▼ ▼ ▼
Old IP DNS IP Certificate
│ │ │
└──────────────┼──────────────┘
▼
Candidate IP
│
┌──────────────┼──────────────┐
▼ ▼ ▼
HTTP TLS Service
Fingerprint Fingerprint Fingerprint
│ │ │
└──────────────┼──────────────┘
▼
Origin Validation
另外一条路径：
Web Application
│
┌──────────────┼──────────────┐
▼ ▼ ▼
Email SSRF Webhook
│ │ │
▼ ▼ ▼
Header HTTP Logs Callback Logs
│ │ │
└──────────────┼──────────────┘
▼
Egress IP
│
▼
Candidate Origin
真正可靠的防御并不是：
“保证永远没人知道 Origin IP”
而应该是：
“即使别人知道 Origin IP，也无法绕过 CDN/WAF。”
这是整个问题最重要的安全思想。
正确架构：
Internet
│
▼
CDN / WAF
│
▼
Firewall / Security Group
│
▼
Origin
源站：
80/443
只允许来自：
CDN / WAF 官方回源 IP 段
的连接。
其他互联网地址：
Internet → Origin:80/443 → DROP
这样即使源站 IP 被公开，也无法直接访问 Web 服务。
仅仅依赖 CDN IP 白名单还可以进一步加强。
常见方案：
mTLS
Origin Certificate
Authenticated Origin Pull
Private Link
Private Network
Tunnel
例如：
Client
↓
CDN
↓
mTLS Authentication
↓
Origin
只有 CDN 持有合法客户端证书才能访问 Origin。
这样即使攻击者：
知道 Origin IP
仍然不能模拟 CDN 回源。
源站主动访问互联网时，不应该直接使用 Web Origin 的公网地址。
更好的结构：
Origin
│
▼
Egress Proxy / NAT Gateway
│
▼
Internet
这样：
SSRF
Webhook
Remote Fetch
PDF Renderer
API Call
看到的是：
Egress IP
而不是：
Origin IP
不要：
Web Origin
│
├── HTTP
└── SMTP
更好的方式：
Web Origin
│
▼
Mail Provider / Mail Gateway
│
▼
Internet
这样邮件 Header 不会暴露 Web Origin 的公网地址。
避免：
www.example.com → CDN → 1.2.3.4
dev.example.com ───────→ 1.2.3.4
应该：
www.example.com → CDN → Web Origin
dev.example.com → VPN / Private Network / Separate Host
开发、测试、管理系统尤其不应该与生产源站共享公网入口。
源站不应该对任意请求直接返回正式网站。
例如：
IP:443
收到无法识别的 Host/SNI 时，应返回：
Reject
Empty Response
Generic Error
而不是直接返回：
example.com Certificate
example.com Website
这可以降低互联网扫描产生的资产关联信息。
但需要注意：
这只是降低信息泄漏，不应该代替源站 ACL 和回源认证。
应该定期检查：
Old DNS
AAAA
MX
Old Subdomain
Dev Domain
Test Domain
Legacy Server
Unused Public IP
Old Certificate
Old Cloud Instance
特别是：
dev
test
stage
staging
old
legacy
origin
backend
admin
等资产。
服务器主动访问外部 URL 时，应考虑：
URL Allowlist
DNS Validation
Redirect Validation
Protocol Restriction
Network Egress ACL
Metadata Service Protection
Private IP Blocking
架构上最好：
Web Application
│
▼
Isolated Fetch Service
│
▼
Egress Proxy
│
▼
Internet
避免 Web Origin 自己直接访问任意互联网地址。
以下服务通常不应该直接暴露公网：
SSH
RDP
MySQL
PostgreSQL
Redis
Elasticsearch
Docker API
Kubernetes API
内部管理后台
更好的访问方式：
Administrator
│
▼
VPN / Zero Trust / Bastion
│
▼
Private Network
│
▼
Origin
错误的安全模型：
攻击者不知道 Origin IP
=
服务器安全
正确的安全模型：
攻击者即使知道 Origin IP
│
▼
Firewall 拒绝
│
▼
无法绕过 CDN
进一步：
Internet
│
▼
CDN / WAF
│
├── DDoS Protection
├── WAF
├── Rate Limit
└── Bot Protection
│
▼
Origin Firewall
│
├── CDN IP Allowlist
└── Origin Authentication / mTLS
│
▼
Reverse Proxy
│
▼
Web Application
│
▼
Internal Services
出站：
Web Application
│
▼
Egress Proxy / NAT
│
▼
Internet
管理：
Administrator
│
▼
VPN / Zero Trust / Bastion
│
▼
Private Network
这才是相对完整的 CDN/WAF 源站保护架构。
在合法授权的安全测试中，不应该简单理解成：
“找真实 IP”
而应该理解成：
Asset Discovery
│
▼
Attack Surface Mapping
│
▼
Origin Exposure Assessment
│
▼
Candidate Origin Discovery
│
▼
Origin Validation
│
▼
CDN/WAF Bypass Assessment
│
▼
Origin Security Assessment
│
▼
Risk Analysis
│
▼
Remediation
最终需要回答的问题不是：
“我能不能查到这个 IP？”
而是：
1. 源站是否能够被识别？
2. 即使源站被识别，互联网是否能够直接访问？
3. 是否可以绕过 CDN/WAF 直接访问 Web 应用？
4. 源站是否还暴露其他网络服务？
5. 出站连接是否会泄漏源站网络信息？
6. IPv6 是否存在遗漏？
7. 子域名、邮件、API、WebSocket、媒体服务器是否泄漏基础设施？
8. 是否存在 CDN IP Allowlist？
9. 是否存在 Origin Authentication / mTLS？
10. 即使 Origin IP 完全公开，整体架构是否仍然安全？
CDN/WAF 源站发现的核心逻辑可以记成：
历史 DNS
+
子域名 / 遗留资产
+
邮件 / 主动出站
+
TLS / Certificate
+
网络空间资产关联
+
Web / API 信息泄漏
↓
Candidate Origin
↓
HTTP + TLS + 服务特征交叉验证
↓
Confirmed Origin
而防御的核心原则是：
不要把“隐藏 IP”当作安全边界。
真正的安全边界应该是：
即使源站 IP 完全公开，
攻击者仍然无法绕过 CDN/WAF 直接访问源站。
iThome鐵人賽
看影片追技術